2.4 GLR Render Intervals

This approach to virtualizing frame buffer real estate and graphics hardware access for a render service is implemented by GLR's render interval mechanism.

A render interval is an interval (of real time) during which a GLR client may perform OpenGL rendering to a rectangular frame buffer region for a guaranteed minimum duration. The interval is explicitly begun and ended by a GLR client. The guaranteed minimum duration and rectangle size are specified by the GLR client when the interval is initiated. The guaranteed minimum duration is bounded by an upper-limit determined by the GLR server.

Multiple render intervals may be initiated concurrently by different GLR clients. The GLR server determines which render interval (or possibly multiple intervals) should be active. When a scheduled interval is activated, the state for the interval's rectangular frame buffer region is maintained, and the client can issue OpenGL rendering commands to render to and read back from the frame buffer.

If a GLR client with an active interval exceeds the guaranteed minimum duration of the interval and another client's render interval is waiting to be made active, the GLR server expires the active client's interval. When an interval is expired, its associated frame buffer state is no longer retained. No immediate notification of the expiration is sent to the client. A client with an expired interval can continue to render though the frame buffer ceases to be updated.

When a GLR client with an active interval ends its interval, the client is informed if the interval was expired. If the interval was expired, the client can make no assumptions about any frame buffer state read back during the interval.

The purpose of expiring render intervals is to ensure that a misbehaved (or simply unexpectedly slow) client will not prevent access by other clients to the render server for arbitrary periods of time. The server's maximum allowed duration ensures other clients will get fair access to the server. Conceptually, GLR render intervals are a type of transaction processing; the rendering ``transaction'' must be completed within the pre-arranged time or the transaction is aborted (render interval is expired).

GLR clients are expected to re-perform render intervals that are expired. Using a measurement of the duration of the expired interval, the client is assumed to have a better estimate of how long a render interval to request. GLR assumes the client can reproduce the rendering requests again.

GLR clients should always be prepared for a render interval to be expired. Intervals may be expired for events beyond the control of the client (network lapses or the client was a paused by the user in the middle of a render interval).

A few important points about GLR render intervals:

• It is only frame buffer state that is lost when a render interval is expired; OpenGL rendering state (including display lists and texture objects) is retained across multiple render intervals.

• GLR provides a means to set up rendering state (including display lists and texture objects) outside of a render interval.

• When multiple GLR clients are concurrently requesting render intervals, the server schedules render intervals not only based on the order the intervals were scheduled, but also on the requested duration of each interval. This scheduling policy encourages clients to accurately estimate their expected rendering time.

• The time spent within a render interval is returned whether the interval succeeds or was expired. This information not only lets the client better estimate expired intervals, but also better bound the time required for successful intervals to the client's scheduling advantage. Generally, clients are well served to add a ``bit of slop'' to requested durations to avoid unexpected slight timing anomalies.

• Even when there is contention due to multiple clients for the scheduling of render intervals, clients are essentially unaware of this contention (except that contention may cause an expiration that might not otherwise have occurred, something all clients should prepare for).

• Nothing forces a client to read back frame buffer state or specifies what frame buffer state should be returned. The client is free to read back subregions of the allocated region, read back only the green pixel components, read back ancillary buffer state like depth buffer values, etc.